AWSセキュリティ成熟度モデルによるセキュリティ現在地確認のススメ

こんにちは、臼田です。

みなさん、AWSのセキュリティ対策できてますか？(挨拶

といっても具体的にどれくらいできているかって判断するのが難しいですよね。

今回はAWSから提供されているAWSセキュリティ成熟度モデル(AWS Security Maturity Model)を活用した、どれくらいできているのかを確認する方法を紹介します。こんな感じになります。

ぱっと見いい感じじゃないですか？これはちょっと作り込んでありますが、ベースはAWSセキュリティ成熟度モデルを活用しています。まずはAWSセキュリティ成熟度モデルがなんなのか、というところから説明していきます。

AWSセキュリティ成熟度モデルとは

AWSセキュリティ成熟度モデル(AWS Security Maturity Model)はAWSから提供されている、組織がAWSのセキュリティ対策をどの程度実現できているかを定量的に測るためのフレームワークです。

以下の図ように9つのCAFベースのセキュリティカテゴリと、それぞれ4つのフェーズで分類されています。

9つのカテゴリは下記のとおりです。

• セキュリティ ガバナンス
• セキュリティ保証
• アイデンティティとアクセス管理
• 脅威検出
• 脆弱性管理
• インフラ保護
• データ保護
• アプリケーションセキュリティ
• インシデント対応

4つのフェーズはこのようになっています。

1. クイックウィン(Quick Wins)
2. 基礎(Foundational)
3. 効率化(Efficient)
4. 最適化(Optimized)

なお、このドキュメントは次のように書かれており(意訳)、公式のドキュメントではないということを補足しておきます。とはいえ、十分活用できるものです。

– このモデルは AWS 公式ドキュメントの一部ではありません。これは、AWS セキュリティ専門家のチームによって作成され、数十のピアレビュー (正式なプロセスではありません) を通じて検証された一連の独自の規範的なガイダンスです。 – 現在、顧客のセキュリティ体制を向上させるために 100 人を超える AWS ソリューションアーキテクトによって使用されており、過去 12 か月で 40,000 人を超えるユニークユーザーがいました。 – 一般的なアプローチに従っていないため、優先順位付けの基準を理解するには「はじめに」セクションを参照してください。 – このドキュメントは Well-Architected や CAF に代わるものではなく、優先順位付けを支援し、学習を簡素化することを目的としています。

このような成熟度モデルの概念は、有名なものだとCMM/CMMIやサイバーセキュリティの分野ではCMMCなどがありますが、これと似たようなものだと考えると良いと思います。ただし、めちゃくちゃAWSナイズされていてより現実的で、AWSをスコープに見るならすごく使いやすいです。

AWSセキュリティ成熟度モデルでは、各セキュリティのカテゴリとフェーズに応じて、どのような取り組みができているといいかが定義されています。

例えば「アイデンティティとアクセス管理」カテゴリの「Phase 1: クイックウィン」では下記の3つが推奨事項として書かれています。

• 多要素認証
• root アカウントを利用せず、さらに監査する
• IAM Access Analyzer によるアクセスとロールの分析

これらが実現できていればOKということですね。わかりやすい基準です。

このように各カテゴリとフェーズにある推奨事項を確認していき、どこまでできているかマルバツつけていくと、自分たちが今どれくらいできているかわかるということです。

そして、そのためのシートも一緒に公開されています！うれしい！Maturity Model Assessment toolsのページにエクセルが置いてあります。

ちなみにこのページの下の方には、AWS Well-Architected Toolで利用できるカスタムレンズのjsonデータもあります。エクセルだけでなく、AWS Well-Architected Toolでこれを使って、結果を保存したり、レポートにしたりすることもできます。

まとめると、AWSセキュリティ成熟度モデルは体系的にまとめられたセキュリティカテゴリとそのフェーズ毎の推奨事項の実現度をチェックすることで、自分たちのAWSセキュリティの現在地がわかるツールということです。

現在地がわかったら、その次の活用方法は様々で、足りないところを補うためにその洗い出し方法として活用したり、組織の中でベースラインとなるレベル感を定義するのに使う事もできます。

また、推奨事項の数は結構ありますが、それらを一通り確認することで、単純にAWSセキュリティへの理解を深める読み物としても活用できます。

AWSセキュリティ成熟度モデルを使う上での勘所

と、一通り概要やメリットについて説明したところで、実際にこれを活用していく上での勘所をザッと箇条書きで共有します。

AWSセキュリティ成熟度モデルを使った取り組みの姿勢

• この成熟度モデルはあくまで指標です
  • この推奨事項に必ずしも寄せすぎる必要はありません
  • この推奨事項で完全なセキュリティ対策ができる、ということでもありません
  • 有効に活用できますが、過信し過ぎないようにしましょう
• もともと組織単位で適用することが想定されていますが、プロジェクト単位で評価してもOKです
  • むしろプロジェクト単位でAWSアカウントが別れていることも多いので、プロジェクト単位の評価に使うほうがいいかも
• しっかり取り組むとアセスメントはぼちぼち重たいです
  • 最初のアセスメントは現在地確認をするつもりで深く考えずに、推奨事項を概要レベルで理解したら「できてる、できてない」の2択でさっくり付けていくぐらいがちょうどいいです
• 「Phase 1: クイックウィン」は文字通り、すぐにできる取り組みです
  • だいたいAWSのマネージドセキュリティサービスを有効化する、とかなのですぐやりましょう
• 私のレコメンドとしては「Phase 2: 基礎」まですべてのカテゴリで実施するところが最低ラインです
  • ここまでできていない項目を洗い出して、その改善から着手するといいでしょう
• 「Phase 4: 最適化」はかなり高いレベルですが、込み入ったレベルでもあるので必ずしもやらなくて良いです
  • 「一般的な目指すべき理想の状態の1つ」でありすべての環境での正解ではありません
• 各推奨事項(これとか)は英語のドキュメントのみなので、ブラウザ翻訳を活用しよう
• 各推奨事項を詳細まで理解しようとするとある程度AWSセキュリティの専門性が必要になってきます
  • ドキュメントを読んでもわからない、ドキュメントが足りないこともあります
  • 社内にいるAWS Certified Security - Specialty有資格者などにも頼りましょう
    • いなければ取得しましょう
  • このブログ後半の解説も合わせて参照してください
• 推奨事項によっては私の見解では必須ではないものもあります
  • あくまで指標です
  • 具体的な項目は後半に解説します

アセスメントツールの使い方

• 全部英語なので、翻訳ツールとかでバッと翻訳するといいです
• デザインが若干古いのと英語のシートあるあるな感じなので、適度にレイアウトや斜めになっている文字とかを調整しましょう
  • これらの調整が終わったら、使い回せるようにマスターデータとして保管しておきましょう
• Googleスプレッドシートなどに変換しちゃうのもありです
• アセスメントを始めるときは、どのようなスコープを対象にして評価するかを定義しましょう
  • 組織全体 or プロジェクトどちらか
  • 対象のAWSアカウントはどれか
• データを入力するシートで、各推奨事項毎に整合性(どれくらいできているか)を入力します
  • できていない部分はコメントに具体的な理由や状況を書いておきます

• 上から順に進めて、「Phase 2: 基礎」まで一通り入力できればそこで止めても問題ないです
  • だいたいここまでで問題があれば、それに対応していくことを優先します
• 入力したあとリザルトシートを確認するとマトリクスの状態で確認できます
  • 特に一番下のPhase毎の合計がPhase1,2共に100%になるところを最初のゴールに設定するのがちょうどいいでしょう

• このリザルトの表でも直感的に分かりづらいので、より見やすい簡易的なグラフとして先程掲載したようなグラフを作ると、他者に対して説明しやすくなります

AWSセキュリティ成熟度モデルの推奨事項の解説

ここからは実際にチェックをしていく推奨事項について解説します。項目が50個以上あるので、Phase 1,2をすべてと、3,4については特筆すべきところをピックアップして解説します。主にその推奨事項で何を考慮するのかという「検討内容」とOKとする基準である「完了条件」を記述しています。

なお、解説の内容は主に弊社のお客様向けの解説になっているので、弊社寄りの話がちらほらありますが気にしないでください。また、あくまで私の一般的な環境に対する見解であり、推奨事項に対する様々な見解や個別の環境における判断があることも考慮して読んでください。

1.1.1 セキュリティインシデント発生時の連絡先を更新する

検討内容

AWSアカウントの連絡先情報で「セキュリティ問い合わせ先」を登録します。万が一AWSアカウントで不正利用等が発生した場合に、この連絡先に通知されるため、常にこれを受け取れるようにして確認する必要があります。

完了条件

クラスメソッドメンバーズのお客様はCMP(クラスメソッドメンバーズポータル)にて「AWSアカウント通知先」で「セキュリティ通知先」を登録すればOKです。

そうでない場合は、ルートユーザーでAWSアカウントにログインし、右上の[Contact information] (連絡先情報)から「主要連絡先」「セキュリティ問い合わせ先」を登録すればOKです。

1.1.2 利用しないリージョンを無効化する

検討内容

リージョンの利用制限はAWS OrganizationsのSCPを利用する必要があり、AWSアカウント単体やプロジェクトレベルの取り組みではなく、組織全体のレベルで行う必要があるため、オプションの対策です。

すでにAWS OrganizationsやAWS Control Towerを利用している場合はこれを行うことを強く推奨します。

完了条件

SCPによりリージョン制限を設定すればOKです。AWS Control Towerを利用していればマネージドの機能を利用を推奨します。利用していなければ「SCPの例」を参考に設定します。

1.2.1 Security Hub によるベストプラクティスの自動化

検討内容

AWS Security Hubを利用してAWS基礎セキュリティベストプラクティスのスタンダードによるAWS環境のセキュリティチェックを実施します。

AWS Security HubはAWS環境のセキュリティチェックを実施することが可能です。AWS Security Hubのセキュリティチェック機能は「セキュリティ基準(スタンダード)」という名前です。複数のスタンダードのうち「AWS 基礎セキュリティのベストプラクティス v1.0.0」を利用することを推奨します。このスタンダードはAWSがメンテナンスを行い、新しいサービスやポリシーがどんどん追加されます。

AWS Security Hubを利用することで、AWS環境の危険な設定を検出して是正するフローを回すことが可能になります。

完了条件

AWS Security Hubを全リージョンで有効化します。「AWS 基礎セキュリティのベストプラクティス v1.0.0」を有効にします。

ここまでで最低限OKとしますが、検出された項目のうちCritical(重大)のものは即時対応をすることを強く推奨します。

「セキュアアカウント」により自動的にこれらの設定を有効化できます。

1.3.1 多要素認証

検討内容

rootユーザーとIAMユーザー/IAMロールあるいは連携しているIdPですべての利用者がMFAを設定しそれを必須としている必要があります。クラウドサービスはインターネットを経由して利用するため、ユーザーID/パスワードのみの認証は極めて危険です。

現代では例外なくすべてのユーザーがMFAを利用します。利用するMFAの種類は仮想MFAの利用で問題ありません。アドオンの対策として、IAMユーザーをほぼ作成しないことを検討します。

完了条件

rootユーザーとすべてのIAMユーザーでMFAを有効化し、人が利用するすべてのIAMロールでMFAを前提としたポリシーを記述すればOKです。

クラスメソッドメンバーズを利用している場合、通常rootユーザーはクラスメソッドが管理しているため委任できます。

IdPを利用している場合にはそちらでMFAが有効になっており、IAMロールでそれを必須の条件として確認できると理想的です。

1.3.2 root アカウントを利用せず、さらに監査する

検討内容

rootユーザーはAWSアカウントで特権を持つユーザーで、特別なユーザーのため通常は利用せず封印することがベストプラクティスです。

完了条件

rootユーザーにMFAが設定され、基本的に使わないようになっていればOKです。

更にCloudTrailを活用してログインしたことをアラートしてもいいですが、コストパフォーマンスは良くないので基本的には必要ありません。

クラスメソッドメンバーズを利用していれば、通常rootはクラスメソッドが管理しているため自動的にOKです。

1.3.3 IAM Access Analyzer によるアクセスとロールの分析

検討内容

IAM Access AnalyzerはAWSアカウント外部から利用できるリソースを検出し一覧表示することで、意図せず公開していないか管理することができるサービスです。

IAM Access Analyzerを有効化し、すべての項目を確認していきます。

完了条件

すべてのリージョンでIAM Access Analyzerのアナライザーを作成します。

「セキュアアカウント」を利用することでアナライザーの作成と維持をクラスメソッドに委任できます。

検出されたリソースが外部からアクセスできて問題ない場合はアーカイブ、そうではない場合は是正をする。すべて対応できたらOKです。

1.4.1 Amazon GuardDuty による脅威検出

検討内容

Amazon GuardDutyを利用します。Amazon GuardDutyはAWS環境上の様々な脅威を検出します。例えばEC2がマルウェアに感染したり、コインマイニングしたり、不正なIAMのログインがあったり、S3のデータの漏洩など幅広いレイヤーの検出が可能です。

まず有効化するだけで非常に効果を発揮するため必須のサービスです。旧来のオンプレミスのような環境では、このような仕組みのために大規模な基盤やシステムが必要でしたが、AWSではポチッと有効化するだけでその恩恵を受けられます。

完了条件

Amazon GuardDutyを全リージョンで有効化していればOKです。

「セキュアアカウント」を利用することで有効化と維持をクラスメソッドに委任できます。

「インシデント自動調査」を利用することで有効化と維持をクラスメソッドに委任でき、更に発展的な運用のサポートを受けられます。

1.4.2 AWS CloudTrail によるAPIコールの監査

検討内容

AWS CloudTrailを有効化しすべてのAPIコールを記録します。AWS CloudTrailはAWSで実行したAPIの証跡をとり監査することが可能です。AWS利用に必須のサービスです。

完了条件

AWS CloudTrailを有効化し、S3バケットにログを保存すればOKです。管理ログのみで問題ありません。

クラスメソッドメンバーズを利用している場合デフォルトで有効化されています。

「セキュアアカウント」を利用している場合はよりセキュアな設定になります。

1.4.3 AWS Trusted Advisor で発見した security findings の修復

検討内容

AWS Trusted AdvisorはAWSのベストプラクティスに従っているか環境をチェックして是正のレコメンデーションを作成する無料のサービスです。AWSのサポートプランに応じてチェックできる範囲が変わります。クラスメソッドメンバーズを利用している場合、すべての項目が利用可能です。

レコメンデーションのうちセキュリティのカテゴリを確認します。

完了条件

AWS Trusted Advisorにアクセスし、セキュリティのチェックを確認します。

アラートが赤(推奨されるアクション)のものを中心に確認します。

やや煩雑に検出されるため、内容を理解し、重大だと思われるものに対応すればOKとします。

詳細な対応はPhase2のセキュリティ保証のスコープとします。

1.4.4 異常検出のための課金アラーム

検討内容

従量課金で利用するクラウド環境では、課金のモニタリングが必須です。これはセキュリティの文脈としても有効で、不正な利用があった場合などにも、資産を守る意味合いで想定される金額を超えた場合の検知が有効です。

AWS BillingやAWS Cost Explorerを活用して料金アラートを設定したり詳細を確認したりできます。

クラスメソッドメンバーズではAWSマネジメントコンソールで正確な利用費を確認できないため、代わりにクラスメソッドメンバーズポータルで利用費を確認し、料金アラームを設定できます。

完了条件

料金アラームを設定したらOKです。

1.6.1 セキュリティグループによるアクセス制限

検討内容

VPCでネットワークのアクセス制御を行うにはセキュリティグループを利用します。セキュリティグループは最小権限の原則に従い、必要なアクセスのみに制御する必要があります。特にSSHやRDPなどの管理アクセスポートを許可する場合には必ず送信元IPを限定する必要があります。

更に現在では管理アクセスポートを開放しなくても、AWS Systems Manager Session Managerなどを利用して管理アクセスが可能であるため、ポートを開放せずに利用することがベストプラクティスです。

完了条件

すべてのEC2インスタンスにアタッチしたセキュリティグループでSSH/RDPポートを開放していなければOKです。開放する場合、送信元IPを/32レベルで制限します。

この確認はAWS Security Hubのチェック項目「[EC2.21] ネットワーク ACL は、0.0.0.0/0 からポート 22、またはポート 3389 への侵入をを許可しないようにする必要があります」が全て対応できていることでも確認可能です。

1.7.1 Amazon S3 のパブリックアクセスの禁止

検討内容

Amazon S3はデフォルトでアカウントレベルのブロックパブリックアクセスが有効になっています。これはS3バケットの設定に関わらず、オーバーラップしてS3バケットの公開を抑制する設定です。通常S3バケットを公開することは殆どないため、アカウントレベルのブロックパブリックアクセスを有効にした状態で利用します。

S3バケットを直接公開する必要がある場合には、アカウントレベルのブロックパブリックアクセスの代わりに、バケットレベルのブロックパブリックアクセスを活用し、必要なバケット以外を保護します。

CloudFrontを利用してS3を公開する場合、S3バケット自体は非公開で利用可能なためブロックパブリックアクセスを有効にしたままにします。

完了条件

通常、アカウントレベルのブロックパブリックアクセスを有効にしていればOKです。

公開するS3バケットが存在する場合には、そのコンテンツの内容とリスクを適切に判断し、それ以外のS3バケットでブロックパブリックアクセスが有効になっていればOKです。

1.7.2 Amazon Macie によるデータセキュリティの分析

検討内容

Amazon MacieはS3に保管されている機密データの検出と保護を行うサービスです。

Amazon Macieを活用することで、S3バケットに保存されている機密データを発見してラベリングが可能になるため、データ設計通りに保管されているか、あるいは不用意に機密データが混入していないかを確認できます。

これらは利用に関する費用の面と運用の難易度でハードルが高いため、オプションとします。ただし、機密を含む重要データの把握やそのポリシー制定は情報セキュリティの基本であり入り口であり本質であるため何かしらの方法で始めから意識すべきです。

完了条件

Amazon Macieが有効化されていれば最低限OKです。

以下の運用があるとより良いです。

• 機密データ自動検出を利用して機密データが保持されているS3バケットを特定している(これは主にPhase2だが、自動で動作させられるのでPhase1にも追加)
• 公開されていたり暗号化されていないS3バケットを特定している
• それらが社内ポリシーに照らし合わせて適切か、必要外の場所に機密データが無いかを定期的にチェックできている

1.8.1 AWS WAF のマネージドルール

検討内容

AWS WAFはAWS環境で透過的に、簡単に導入できるWebアプリケーションファイアウォールです。AWS WAFはマネージドルールが提供され、OWASP トップ 10に対する保護などが可能になります。

定常的なアプリケーションに対する攻撃の対策のほか、新規に発見された脆弱性への即時対応やDDoSからの保護、高度なBOTや標的型攻撃からの保護など、いざという時にすぐに使えるように基本構成として導入すべきです。

完了条件

外部向けに公開しているAmazon CloudFront / ALB / API Gateway / AWS AppSyncに対してAWS WAFのWeb ACLをアタッチし、有用と思えるマネージドルールを適用していればOKです。

1.9.1 Amazon GuardDutyの検出に対応する

検討内容

Amazon GuardDutyにより検出された脅威がある場合、これに対応します。緊急度が高のものは、非常に危険であり攻撃者からの影響を受けている可能性が高いです。即時封じ込めを行います。

緊急度が中低のものはPhase2の脅威検出の範囲とします。

完了条件

1週間Amazon GuardDutyが緊急度高のものを検出しない状況になっていればOKです。

2.1.1 セキュリティおよび規制要件を特定する

検討内容

対象のAWS環境及びサービスなどのアセスメント対象のワークロードや組織自体に求められるコンプライアンス要件を確認します。

例えば金融系のサービスであればFISCの要件があるとか、自社の情報セキュリティポリシーや準拠すべきスタンダード・セキュリティチェックリストなどの要件などが対象です。

特にない場合には、クラスメソッド推奨としてまずはAWS Security Hubを利用したセキュリティチェックの運用をルールにすることを推奨とします。

完了条件

ここでは満たすべき要件を決めたらOKです。サードパーティのCSPM製品などでルールを決めてもOKです。

2.1.2 Cloud Security のトレーニングプラン

検討内容

AWSの利用者とAWSの管理者向けにAWSセキュリティの前提知識を身につけるためのトレーニングメニューを構成します。

AWSはインターネットの先に存在するサービスです。プライベートな社内の検証環境などではないため、AWSの利用者はAWS利用の前に最低限のセキュリティの教育を受ける必要があります。

AWSの管理者はAWSの特徴とその上に構築するワークロード、自社のセキュリティポリシーを理解してそのセキュリティに責任を保つ必要があります。AWSのセキュリティ機能をよく理解し、これを管理運用するための知識が必要です。

完了条件

すべてのAWS利用者にIAMの扱いについて基本的な教育を実施する規則とし、これを運用できていればOKです。実際に利用するコンテンツとしてはAWSランプアップガイドのIAMに関する学習リソースなどが活用できます。

プロジェクトのAWS管理者や組織全体のAWS管理者に対するAWSセキュリティ知識を習得する機会が整備されていればOKです。資格としてはAWS Certified Security - Specialty相当の知識を基準とします。「AWSトレーニングサービス」で「Security Engineering on AWS」を活用すれば3日間でセットアップできるためこれも選択肢とするといいでしょう。

2.2.1 AWS Config による構成管理

検討内容

基本的にはAWS ConfigをマネージドしているAWS Security Hubの運用により、各種AWSの基本的なセキュリティ設定が満たされていることを確認することで満たすとします。

完了条件

例えば以下のような項目の監視と是正が適切に運用できていることでOKとします。(もっとたくさん対象にして構いません)

• セキュリティグループでSSH/RDPポートが0.0.0.0/0で公開されていない(EC2.19)
• バケットレベルで S3 ブロックパブリックアクセス設定が有効になっている(S3.8)

新しい項目が検出された際に通知できるようになっているとより適切です。

「セキュアアカウント」を利用すればAWS Security Hubの有効化と適切な設定が自動的に完了し、通知を簡単に始めることができます。

2.3.1 ユーザーリポジトリの一元管理

検討内容

組織の中で、ITシステムに対するアクセス制御は一元管理されることが望ましく、AWS環境もそのうちの1つです。ベストプラクティスに基づいて環境分離することで、利用対象のAWSアカウントは増えていくため、個別にIAMユーザーを作成することはアンチパターンになります。

Azure Active DirectoryやOktaなど、一元的なIdPにユーザー情報が集約され、組織全体のガバナンスを適用します。

AWSのみのスコープでユーザーリポジトリの集約を検討する場合、大きく2つの方法があります。

ベーシックな方法としては、1つのAWSアカウントにIAMユーザーを集約し、他のAWSアカウントにはスイッチロールしてアクセスする、Jumpアカウント方式です。これは環境条件もほぼ無く始めやすい手段です。

より発展的な手法として、AWS Organizationsと連携してAWS IAM Identity Centerを利用したSingle Sign-Onです。これは関連するAWS環境を束ねるAWS Organizationsを利用する必要があるため、その他の要件と合わせて検討します。

完了条件

AADなど組織で従業員のIdentityを一元管理する仕組みがあり、これと連携してAWS環境へのアクセスが提供されていることが理想の状態でOKです。

組織全体のIdentityを利用できない場合には、限定的な集約がされればよく、例えばJumpアカウント方式やIAM Identity Centerで集約する手法が利用できていればOKです。

Identityを管理するレイヤーと、それを継続的にメンテナンスする体制があり、各ユーザーには効率的に、かつ最小権限でアクセスが提供されていればOKです。

2.3.2 組織ポリシーとしてのSCP

検討内容

AWS OrganizationsのSCPを駆使して組織のガードレールを整備します。SCPを利用すれば、組織内のガードレールを展開していくことが可能です。利用するリージョンの制限や整備したCloudTrailやGuardDutyなどのサービスの停止を禁止するなどが可能です。

AWS Organizationsが必要なためオプションとします。クラスメソッドメンバーズを利用していてAWS Organizationsを利用される場合は「組織管理プラン」をご利用ください。「マルチアカウント管理」「CCoE支援」にてこの項目を満たすための支援が可能です。

完了条件

リージョン制限やベースラインサービスの停止禁止などのポリシーを検討して、SCPを利用してこれを実装できていればOKです。

2.4.1 Amazon GuardDuty の findings を調査する

検討内容

緊急度が中低のものが頻繁に出る場合にはアーキテクチャに問題があります。根本的に構成を変えることを検討しましょう。

クラスメソッドメンバーズでは「インシデント自動調査」を利用することでよりわかりやすい解説とレコメンデーションを受けることが可能です。

完了条件

1週間Amazon GuardDutyが何も検出しない状況になっていればOKです。

2.5.1 インフラストラクチャの脆弱性を管理し、ペネトレーションテストを実施する

検討内容

Amazon Inspectorを利用した脆弱性情報の収集と管理を行います。

完了条件

Amazon Inspectorにより発見された、EC2/ECR/Lambdaに関する脆弱性を適切にハンドリングして対処できていればOKです。

代替えアプローチ

以下の領域が可能なソリューションを利用し、運用します。

• 脆弱性情報の収集
  • Amazon EC2インスタンスに対するソフトウェアインベントリの収集
  • Amazon EC2インスタンスに対するカーネル・ミドルウェア等の既知の脆弱性(CVE)の定常的なチェック
  • Amazon ECRコンテナイメージに対するカーネル・ミドルウェア等の既知の脆弱性(CVE)の定常的なチェック
  • AWS Lambdaに対するカーネル・ミドルウェア等の既知の脆弱性(CVE)の定常的なチェック
  • AWS Lambdaに対するアプリケーションコードの作り込まれた脆弱性(CWE)の定常的なチェック
• これらの結果を元に対処が検討され、それが実施されてればOK

2.5.2 アプリケーションの脆弱性管理

検討内容

アプリケーションにおける脆弱性の混入は開発プロセスでツールを活用し自動化してある程度防ぐことができます。アプリケーションコード診断する静的診断(SAST)やアプリケーションを動かして攻撃をシミュレートする動的診断(DAST)のツールを活用すると良いです。これらを開発プロセスに導入して自動化することで安全な開発が実現できます。

非常に難易度が高いのでPhase3や4での検討ぐらいでOKです。

オープンソースのツールを活用してもいいですし、Snykなどサードパーティソリューションを活用することも推奨します。クラスメソッドではSnykの導入支援が可能です。

完了条件

パイプラインの中に適切に脆弱性管理の仕組みが導入され、適切に運用できていればOKです。

2.6.1 AWS Systems Managerによる管理アクセス制御

検討内容

元のタイトルの訳は「Fleet Manager によるインスタンス管理」ですが、こちらに読み替えていただくと適切です。

EC2インスタンス等の構築したAWSインフラに対するSSH/RDPなどの管理アクセスには、直接ネットワーク的にアクセスせずに、代わりにAWS Systems Manager Session ManagerやFleet Managerを利用してアクセスします。

完了条件

SSH/RDPのポートを一切インターネットに公開しなければOKです。

2.6.2 VPC内の Public/Private ネットワーク分離

検討内容

VPC内の各リソースは適切なサブネットに分割して配置する必要があります。

役割や必要性に応じて分離することで、外部から受ける影響(アタックサーフェイス)を減らし、影響があっても爆発半径(Blast Radius)を小さくできます。

基本的にパブリックサブネットにはEC2インスタンスなどを設置する必要性はありません。現在ではSystems Manager Session ManagerやEC2 Instance Connectを活用してプライベートサブネットのEC2インスタンスに直接管理アクセスすることが可能です。

完了条件

VPCでパブリックサブネットにEC2インスタンスを設置していなければOKです。

RDSなども別のサブネットに分離できているとより良いです。

2.6.3 AWS Control Tower によるマルチアカウント管理

検討内容

AWS Control Towerを利用することで、マルチアカウント管理を円滑に行うための初期セットアップや運用が可能になります。

ID管理、ガードレールの整備、アカウント発行フロー整備、ログ管理監視などの機能をAWS Control Towerを利用することで簡単にできます。

AWS Control Towerの利用自体にハードルが高いためオプションとします。「マルチアカウント管理」「CCoE支援」にてこの項目を満たすための支援が可能です。

完了条件

AWS Control Towerを利用するためのマルチアカウント管理に関する設計を行い、全体で守るべき要件が決められ、AWSアカウントの発行から利用まで運用のフローができている状態でOKです。

2.7.1 AWS KMSによる暗号化

検討内容

AWS上に配置するすべてのデータはユーザーの責任により管理されます。これはAWSの責任共有モデルにより定義されています。

AWSの各種ストレージ上で保管するデータ(Data at Rest)については、ユーザーが設定することで保管時の暗号化が可能です。これにより物理的な経路でのデータアクセスを防止し、またコンプライアンスを満たすことが可能です。

データの保管時の暗号化について検討する際は、「なぜ暗号化するのか？」ではなく「なぜ暗号化しないのか？」から検討します。少なくともAWSの上では低コストで保管時の暗号化が実現でき、組織が扱うデータを管理する説明責任を果たすためには暗号化しない選択肢はありません。

AWS KMSを利用するとデータへのアクセスをユーザー側で管理することが可能になります。鍵を破棄することによる暗号化消去(Cryptographic Erase: CE)も可能になり、顧客に対する説明責任を果たせます。

個人情報や機密データを扱うストレージではAWS KMSを利用して保管時のデータを暗号化し、最終的にデータを削除する際には暗号化消去を実施できるようにします。

完了条件

AWS上で保存するすべてのデータに保管時の暗号化が適用されていること。

S3などでデフォルトのサービスの鍵を使用して暗号化をしていてもOKですが、個人情報や機密データを扱うものはAWS KMSで個別に鍵を作成してこれを適用していればOKです。

2.7.2 データバックアップ

検討内容

データのバックアップは様々な目的で必要になります。データやシステムの可用性の確保したり、ランサムウェアの対策としてデータの喪失を防いだりします。その要件も対象毎に異なり、復旧までの許容できる時間やデータの範囲(期間など)を、BCDR等目的のために定義をしていきます。

AWS Backupは各種リソースのバックアップを一括で管理し復元までサポートします。まとめて設定できる部分は積極的にAWS Backupを利用しましょう。

完了条件

それぞれのデータでバックアップの目的と要件を定義し、その通りにAWS Backupや各サービスの設定を使ってバックアップ設定ができていればOKです。

実際に想定通りに復旧できるか訓練していると尚良しです。

2.7.3 Amazon Macie による機密データの発見

検討内容

Amazon Macieを利用することで、S3バケットに保存されたデータから機密情報を発見することができる。これにより、正しく想定通りのデータが格納されているか、あるいは想定外の機密データを保管していないか確認できます。

完了条件

組織あるいはプロジェクトで守るべき情報とその重要度が定義されている。

その上でAmazon Macieが有効化されて以下の運用があるとOKです。

• 機密データ自動検出を利用して機密データが保持されているS3バケットを特定している
• 公開されていたり暗号化されていないS3バケットを特定している
• それらがポリシーに照らし合わせて適切か、必要外の場所に機密データが無いかを定期的にチェックできている

2.8.1 開発時にセキュリティチームも参画する

検討内容

セキュリティはすべての物事に必要となる基本項目であり、アプリケーション開発においても初期から検討すべき内容です。

しばしばアプリケーション開発では、セキュリティに関する考慮が蔑ろにされ、リリース直前になってからしか、あるいはリリースされてからもセキュリティ対策について考慮されていない場合があります。

そのようなことが無いよう、開発の初期段階からセキュリティのプロフェッショナルが参画する必要があります。

完了条件

スコープがプロジェクトの場合、該当プロジェクトでセキュリティ部門が設計に関与できているか、あるいは開発チームに、セキュリティを主導しながら開発できるセキュリティチャンピオン(3.4.2の推奨事項参照)が在籍していればOKです。

スコープが組織の場合、上記のような取り組みが組織の仕組みで常に適用されるようになっていればOKです。

2.8.2 AWS Secrets Manager を利用し、コードにシークレットを埋め込まない

検討内容

アプリケーションコードにクレデンシャルを直接記述することはアンチパターンです。AWS Secrets Managerを活用してこれを外出しすることが可能です。

完了条件

以下の項目をアプリケーションコードに直接埋め込まないようにします。

• IAMアクセスキー
• SSH鍵
• データベースユーザー/パスワード
• OAuthトークン
• APIキー
• その他連携サービスの認証情報

環境変数の利用も基本はNGとし、リスクベースで例外判断します。

シークレットの格納先はAWS Secrets Managerを基本とし、AWS Systems Manager Parameter Storeのみでの格納する場合はローテーションが不要かなど確認します。

2.9.1 インシデント対応手順を作成し、テストする

検討内容

Amazon GuardDutyの検出をトリガーとしてどのようにそのトリアージ・調査・対応を行うか想定して訓練します。

クラスメソッドメンバーズでは「インシデント自動調査」を利用すると、トリアージ・調査が自動化され、受け取った調査結果を元に最終判断をして対応するだけになるためおすすめ。

AWSインフラのセキュリティインシデントの他に、対象ワークロードの可用性の問題など、他の領域のインシデントに対する対応手順や訓練も検討できるとなお良いです。

完了条件

Amazon GuardDutyによる検出を受け取った際の通知が受け取れるようになっていて、これをどのように対応するか担当者やフローが決まっていて、実際にGuardDutyのFindingsを発生させて対応できればOKです。

2.9.2 Multi-AZ による冗長構成

検討内容

アプリケーションの可用性を確保する場合、Multi-AZでの構成を意識する必要があります。

VPCサービスの場合にはその要件に合わせて、SPOFを作り込んでいないかやフェイルオーバーが許容できる時間やサービス停止で実現できるのかを確認します。

完了条件

サービスの可用性要件が定義され、それを実現するための構成がされていればOKです。

復旧の訓練ができているとなお良いです。

 

ここまでPhase 1,2の解説でした。以下はいくつかPhase  3,4から抜粋して解説します。

3.4.2 開発チーム内のセキュリティ能力を高める(セキュリティチャンピオン)

検討内容

セキュリティの課題は組織の様々な場所に存在し、各アプリケーションにはそのビジネスコンテキストを把握したセキュリティ対策が必要になります。そのため、情報システム部門など組織の中央でセキュリティをコントロールすることも重要ですが、各開発チームの中にも開発者としてセキュリティをリードするメンバーが必要です。このメンバーは組織の中央や組織内のセキュリティコミュニティと連携しながら、自身の開発チームでビジネスコンテキストを理解し、開発のアジリティを確保しながらセキュリティも担保する役割が期待されます。

AWSではこのような役割をセキュリティチャンピオンと呼び、AWS社内でも同じように取り組んでいます。

この取り組みを実現するためには、組織全体の構造的な仕組みづくりに対する経営層のコミットと、育成が必要です。

この取り組みの始め方の1つのアプローチとしては、まずAWSセキュリティの機能に絞って、CCoE組織が各開発チームのAWSセキュリティ人材を支援・育成することでAWSセキュリティチャンピオンとするところから始める方法が考えられます。これにより権限を各チームに委任していくことができます。

下記が参考になります。

完了条件

組織の中でセキュリティチャンピオンの取り組みが回っていればOKです。

3.6.2 マルウェア対策やEDRの実装

検討内容

コンピューティングリソースは外部からの攻撃を受けた時に大きな影響を受ける場所の1つです。コインマイニングやマルウェア感染などを防ぐためにホスト上で動作するソリューションが必要になります。

Trend MicroのCloud One Workload Security(以下C1WS)はアンチマルウェア以外にもIDS/IPSやセキュリティログ監視など多層的な保護機能を利用できます。クラスメソッドではC1WSを特に推奨しています。

製品の導入だけではなく監視や運用も適切に行う必要があります。

クラスメソッドでは運用代行のサービスとしてフルマネージドDeepSecurityオプションを提供しています。

完了条件

C1WS等の製品が導入され、適切に運用されていればOKです。

代替えアプローチ

Amazon GuardDutyのMalware Protection機能でもこの一部は満たすことができますが、基本は併用を考えます。

特に重要資産(情報)の経路上のEC2インスタンスはGuardDutyだけでは不十分なためC1WSは必須とします。

それ以外のEC2インスタンスはGuardDutyだけでもOKとします。

3.8.2 Shield Advanced: 高度なDDoS攻撃の緩和

検討内容

参考リンク「AWSによるDDoS緩和のベストプラクティス」に沿ってこの内容を達成します。

以下のベストプラクティスが検討対象です。

• レイヤ 3 (UDP リフレクションなど) 攻撃の軽減
• レイヤ 4 (SYN フラッドなど) 攻撃の軽減
• レイヤ 6 (TLS など) 攻撃の軽減
• 攻撃対象領域を減らす
• アプリケーション層のトラフィックを吸収するスケール
• レイヤ 7 (アプリケーション層) 攻撃の軽減
• 過剰なトラフィックと大規模な DDoS 攻撃の地理的な分離と分散

AWS Shield Advancedを契約するだけで満たせる項目ではないことに非常に注意が必要です。ワークロードに対する総合的なDDoS対策が必要です。

完了条件

「AWSによるDDoS緩和のベストプラクティス」の内容を実現できていればOKです。

3.9.2 AWS Configによる非準拠リソースの自動修復

検討内容

基本的にはAWS Configを直接利用するより、AWS Security Hubを利用して対応していきます。自動修復は参考リンク「AWS での自動化されたセキュリティ対応」が活用できます。ただし、自動修復は自動的にリソースが更新されるためその動作をよく理解し、よく検証した後完全に自動化して問題ないものから適用していく必要があります。

AWS Security Hubでカバーできないより自組織に特化した要件を扱う場合にはAWS Configのカスタムルールを活用します。

完了条件

適切に検証された自動修正の仕組みが導入できていればOKです。

4.8.1 DevSecOps

検討内容

DevOpsのフローに合わせて、もちろんセキュリティも組み込まれる必要があります。一方でセキュリティに対する考慮やその自動化は開発者にとって馴染みが薄く始めることが困難かもしれません。

参考リンク「Security for Developers」を活用することで、SAST、DAST、SCAなどのセキュリティ機能をパイプラインの中で動作させることが可能になります。

OSSを利用したり、Snykなどのサードパーティを活用してこれを実現しましょう。

完了条件

パイプラインの中にセキュリティを組み込めていればOKです。

4.9.2 Amazon Detective: 根本原因の分析

検討内容

Amazon Detectiveを有効化し、Amazon GuardDutyで検知されたインシデントの調査ができる体制を作ります。

完了条件

「セキュアアカウント」か、「インシデント自動調査」によりこの項目の有効化は自動的にOKとなります。

「インシデント自動調査」では調査結果をそのまま受け取ることができるようになりOKです。

その他の場合はAmazon Detectiveを実際に活用して分析できる体制を作ればOKです。

Phaseやカテゴリの変更を検討する推奨事項

私の推奨として、下記の変更を検討するとより現実的な分類になると思います。

• 4.9.2 Amazon Detective: 根本原因の分析はPhase 2へ
• 2.5.2 アプリケーションの脆弱性管理はPhase 3へ
• 3.6.3 送信トラフィックの制御はPhase 4へ

追加の検討事項

私の推奨として、下記を追加項目として含めるとより良くなると思います。

• Amazon Inspectorは有効化するだけで様々な脆弱性のチェックができるのでクイックウィンに追加してもいいかも
• コンテナセキュリティは特殊な対応が必要になる項目のため「インフラ保護」のPhase3とかに追加してもいいかも

まとめ

AWSセキュリティ成熟度モデルを紹介して、実際にどうやって使っていくかの勘所を紹介しました。

これを活用することで自分たちのAWSセキュリティの現在地を確認でき、その先の取り組みに繋げていくことが可能になります。

ぜひ使ってみてください。